TPUG - Toronto PET Users Group

home *** CD-ROM | disk | FTP | other *** search

/ TPUG - Toronto PET Users Group / TPUG Users Group CD / TPUG Users Group CD.iso / AMIGA / AMICUS / AMICUS08.ADF / Scrimper / Messages < prev next >

Wrap

Text File | 1986-04-02 | 19KB | 408 lines

Hey friends! This month we have to begin with the great news that CBM has secured a refinancing of their debt which will ensure their fin- ancial integrity well into next year. This means it's up to us now. We as developers have the responsibility of turning out quality products for public consumption. We as consumers have the responsibility of demanding excellence from the manufacturers of Amiga products. We all know the Amiga personal computer is a leading edge product of high quality. One thing that has been a recurring obstacle to the market ac- ceptence of the Amiga is prevailing unjustified negative press. Column- ists in many of the trades dismiss the Amiga as an inconsequential entry by that long standing producer of toy computers. They can't see beyond their monochrome, low resolution, low performance, non-expandable Big Banannas. I really get the impression that manufacturers in the staid world of yesterday's technology have banded together to turn their col- lective back against a product that simply represents the bell tolling the end of their reign of mediocre machines for the mass market. Conspiracy? Just might be possible. Big advertising budgets often dictate editorial policy. The really mind blowing thing is that Commodore has not been combatting the Amiga-Blahs in the press with persuasive arg- uments to the contrary. Where's the Amiga advertising budget gone? Is there one? How come such things as a recent ad from a mass-merchandiser of the Atari ST attirbuted the characteristics of the Amiga to the Atari the the specifications and characteristics of the Atari to the Amiga go uncontested? So, you might be asking where's Perry going with all this? Well, I spoke of responsibilities before. We've all got one very important responsibility that we've got to start picking up upon. That is, WE can help create a better informed public which up till now has not had the benifit of balanced coverage of the Amiga personal computer. CBM's financial security will last a year. Without us to counter the prevailing misunderstandings by the public the year will come and go. We've got to make the product stick. We've got to demonstrate to others what we've seen ourselves. The Amiga is a technologically superior prod- uct offering enough performance and features to finally make the personal computer a powerful, effective tool providing an adequate human-machine interface. What can we do? Simple! Write letters to editors saying: o ``How come you don't mention or cover the Amiga in your publication?'' o ``Your articles/editorial/advertisement did not repres- ent the truth sufficiently. Let me correct you on the following points:'' And, we can talk. The prevailing views we have to combat are: o CBM cannot produce a quality product. Or, CBM: Don't they make toys? It's funny. But, in Europe, CBM enjoys the opposite rep- utation. They are THE business machine maker. At the very least you can always say: ``But CBM didn't produce the technology. Amiga (a Californian start-up) did.'' o The Amiga doesn't have an IBM-PC emulation. Not true. There are currently two PC emulation products available which work quite well. CBM's commitment is to have the top 25 IBM PC business packages running on the Amiga. o The Amiga is not a serious business computer. Why? Because it can take 8.5 megabytes of memory directly? Maybe it's because its c.p.u. offers nearly the same per- formance as computers in the 100 to 200 thousand dollar range? And those machines don't have the same level of hardware support for graphics and sound. Yeah, maybe it's because the Amiga can compute and render hundreds of thou- sands of graphics elements per second. A real business environment can't possibly benifit from such things. So? Let's Get Tough! User Group Information #2 --- News From JAUG This is the last month I expect to relay news from the Jersey Amiga User Group for a while since (hint hint) readers will start sending infor- mation about their user groups and meetings to AC for publication here. You can send information about your local group to: USMail: Miga-Mania c/o Amazing Computing PiM Publications Inc. P.O. Box 869 Fall River, Ma. 02722 Usenet: ihnp4!ptsfa!well!perry Compuserve: Don Hicks 76714,2404 The February 21st meeting of JAUG was attended by approximately 240 people. We were treated to demonstrations of Amiga music products by Cherry Lane Technologies, Inc. as well as two demonstrations of MIDI wizardry by Lou Ploch of Micro-W Distributing. In fact, we heard a few Rag Time pieces played in Scott Joplin's own hand (and recorded by piano rolls) by MIDI synthesizers controlled by an Amiga personal computer. Next month's focus will be upon business software as well as upon repair and service of the Amiga. Representatives from Commodor-Amiga will be present for the answering of questions. The meeting will be held Friday, the 21st at 7:30. Lecture hall 114 of Hill Center, Rutgers University New Brunswick campus. Hill Center is off of Brett Rd which is off of Metlars Lane which is off of River Rd which intersects Route 287 at exit 5 (consult a New Jersey map). General Helpful Advice #4 --- Amiga RFI (Radio Frequency Interference) Anyone who has ever opened up their Amiga personal computer to see what was inside was greeted by yet another sealed box made of metal. Inside the plastic case is a metal case whose purpose is to contain radio frequen- cy interference caused by the Amiga and prevent such interference from im- pacting other home products such as radios, t.v.'s and your home's electri- cal system. The shielding can only be effective if your Amiga is connected to a fully grounded electrical source. If your Amiga is not fully grounded you will definately experience interference caused by the Amiga on other home appliances. Moreover, intereference caused by an improperly grounded Amiga may even cause what appears to be disk errors when reading from the Amiga's floppy disks. These errors (on reading) will go away when the computer is properly grounded. If, however, you write to a disk drive using an improp- erly grounded machine, you might be writing bad information. Errors of this sort will not go away. By the way, if you are using an adapter to connect your Amiga to a two conductor electrical outlet, you're definately not grounded. In summary, if you can use your Amiga without noticing any noise over televisions or stereos running at the same time, you're probably ok. Also, if you experience a lot of disk failures check to see if you do have interference on a t.v. or radio. If so, your problems may be caused by im- proper grounding. Intuition #3 --- Messages and Message Ports Although this note is grouped under the heading of ``Intuition,'' its scope encompasses any instance of messages and message port usage. One of the primary means of interprocess communication on the Amiga personal computer is the message. Messages can contain arbitrary informat- ion. For example, a message may be empty. It relays information simply by arriving at some destination. Or, a message may contain a C language struc- ture specifying, for example, the position of the mouse with repect to the upper left corner of a window. Because the programmer has complete control over the content of a message, message passing can be used to convey any kind of information from one task or process to another. One way programmers will routinely use messages and message passing is doing device i/o. On the Amiga, processes don't themselves do physical i/o. That is, processes themselves don't normally have to diddle machine registers to make an i/o go. Instead, a process opens a device (which makes sure that a device handler exists and is loaded into memory), formats a (device specific) message, then passes the message to the device handler. The device handler is a piece of code written specifically to handle the grungy details of controlling some device so that we won't have to. Our interaction with devices is accomplished via a nice clean message based interface. Messages are things which are passed from one place to another. So, we should first talk about how to set up a message destination. Message are sent from a process to a ``Message Port'' (or simply, a ``port''). Another process reads the message from the port and sometimes will reply to the message (sending a message back to the originating task or process). So, a message port is a message destination. If you wish to send a message to someother process you must locate its port. If you wish to receive messages (or replies to your own messages) you must declare a message port of your own. To create a port use the call CreatePort supplied in the standard Amiga library. Synopsis: struct MsgPort *CreatePort(name , priority); char *name; char priority; This means that CreatePort returns a pointer to a structure of type MsgPort. The arguments are a pointer to a string which represents the port's name and a byte representing the priority of the port. A port should be given a name when you want to make the port ``pub- lic.'' That is, your desire is to have many different processes or tasks all use the same message port for communication. For example, you might define a message port over which all requests for a data base search might be routed to a data base access program. The data base manager declares the port and gives it a name (which when using CreatePort will automatically make it a public port). Programs which wish to use the data base manager will look for its message port (using FindPort) via the predefined name. When doing defice i/o, a public message is not needed since their will be only two specific parties to the message communication. These are: your process and the device handler. The priority field passed to the CreatePort call is used to influ- ence where in the list of all public message ports this port will be insert- ed. If you are not providing a name for the message port then there's no need to set this field to anything other than 0. If a priority is given, the message port will be inserted no further down the list than the last message port having the same priority. In the grand scheme of things, a message port's priority doesn't really affect performance all that much. CreatePort creates a message port configured to cause a signal to be sent to your task or process each time a message is sent to the port. Sig- nals are another form of interprocess communication (IPC) available on the Amiga. They are used (in this case) to notify a process that there is something interesting waiting for it on a message port. CreatePort performs the Amiga calls to allocate a signal and tells you which signal will be used by this message port in the field ``mp_SigBit.'' You could use this to allow your process to sleep (not use c.p.u.) when it is waiting for activity on the message port like so: Wait(1L << myport->mp_SigBit); That is, wait for a signal whose number is mp_SigBit. Other signals can be ``or'ed'' into a Wait call to allow your process to woken up for any one of several signals. Now, having called CreatePort, you've got a port set up. This port might be used as a destination of replies sent as a consequence of your sending messages to someplace else, or your port might be used as a dest- ination for messages other process might want to send you (by the way: if you need to reply to a message sent to you, the message port to reply to is contained in the message you receive). The next step is to send a message. A message has the following form: +-------------------------------+ | standard Amiga message header | +-------------------------------+ | user defined data structure | +-------------------------------+ There is a field in the standard Amiga message header which defines the length of the user defined data to follow. The Amiga message handling routines are not concerned with the content of the user defined data area. This area is completely dependent upon the programmer for defninition, mean- ing and usage. Here's an example of a user defined message which might be sent from some process to a data base manager: struct DBMS_message { struct Message m; struct DBMS_data d; } db_message; where ``m'' is an instance of the standard Amiga message header and ``d'' is a structure defined and understood by both the program and the data base manager. Before using db_message, we'd specify how many bytes of data were in the message by saying: db_message.m.mn_Length = sizeof(struct DBMS_data); If a reply from the data base manager is required, we also have to specify a port of our own creation to act as a destination for the reply message sent by the data base manager back to us. /* previously createported a message port whose pointer is in ``myport'' */ db_message.m.mn_ReplyPort = myport; We use the PutMsg call to send a message. PutMsg takes a pointer to the destination port and a pointer to the message to be sent. Notice, in our example of a process talking to a data base manager, two ports are envolved. Your process had to do a FindPort to find the public message port used by the data base manager as a collection point for messages to the data base manager. Also, you had to CreatePort your own port to be used as the destin- ation of any reply messages sent from the data base manager back to you. Synopsis: PutMsg(port , mesg) struct MsgPort *port; /* mesg is a pointer to an instance of your application specific message structure */ One really important characteristic of the kind of message passing the Amiga employs is that once you have called PutMsg, you must promise not to modify the contents of the message. In fact, you shouldn't even read from the mes- sage after calling PutMsg since the contents may be undefined. Once you've received your reply you're free once again to use and modify the message structure and contents. Think of it this way: By calling PutMsg you are lending the memory in which the message sits to another pro- cess. If you were to modify that memory while the other process beleives it has control of the memory you might be screwing something up. Also, if the other process modifies the memory, it might be over writing some information you thought was still valid. The reply is the other process'es way of sig- nifying you that it is done using the memory you loaned it. This restriction (of not referencing the contents of a message until you've received a reply for it) is a general rule and may not apply in all cases. However, it pays not to violate the restriction even if you think you might be able to get away with it (something about not tempting fate might be in order here). You can get a message by calling GetMsg and furnishing a pointer to the message port you wish to interrogate. If a message is available for you on the supplied port, GetMsg returns a pointer to the message structure. If there is no message waiting for you at the time on the given port, GetMsg will return NULL. Usually you'll be sitting in some Wait call. When a message arrives for you on one of the message ports whose signal bit you've specified in the argument to Wait, the Wait call will return. Then you'd call GetMsg for each of the possible message sources. The WaitPort call may also be used if you are going to wait for activity from exactly one source. Replying to a message is accomplished via the ReplyMsg call. This call is passed a pointer to a user defined message. The standard message header field ``mn_ReplyPort'' must have been initialized to be the destinat- ion port for replies. Synopsis: ReplyMsg(mesg) In our data base manager example, your process might send a message to the data base manager requesting that a specific record be searched for. The data base manager would perform the search and if the record was found load it into the space reserved for it in the user defined message sent by your process. If the record was not found the data base manager could set some flag which would be checked by your process before trying to use the data returned by the data base manager. While the data base manager performed its work, your process would be waiting for a reply. When the reply comes, it means that the data base manager if finished processing your request and that you can now find the results in the data structure your had originally passed. Here's a summary of how to set up two processes sending messages back and forth. One process is a server (like a data base manager) and will not generate messages on its own but only reply to messages sent to it by other processes. Your Process Server ------------ ------ 1. start-up 1. start-up 2. declare public message port named Ralph 3. Look for public message port 3. Wait for message on named Ralph Ralph 4. Declare private message port (no name but call it myport) 5. Declare message (call it mymess). Mymess has standard message header called m as one field. 6. mymess.m.mn_Length = sizeof(user defined data area) 7. mymess.m.mn_ReplyPort = myport; 8. mymess.user_definable data gets stuff. 9. PutMsg(ralph,&mymess) 10. Wait(1L << myport->mp_SigBit); 4. Server wakes up. 5. msg = GetMsg(ralph); 6. process message 7. formulate reply 8. ReplyMsg(msg); 11. Process wakes up. 9. goto 3. 12. (void) GetMsg(myport); 13. Look at results. 14. goto 8. AmigaDos Bugs #2 - Early Versions Of Delux Paint Will Eat Themselves This isn't really an AmigaDos bug, but we'll put it under this head- ing to reduce the proliferation of Miga-Mania topics. Early versions of Elec- tronic Arts' program Delux Paint may destroy themselves if they are written upon. What happened is EA didn't know that when a disk fills up, the free map of the disk is thrown away and a new one is recontructed at a later time. The problem is that when the free block map is recreated, AmigaDos tries reading the bad sectors EA places on each disk to implement their copy protection scheme. Ordinarily, the sectors wouldn't be considered but since the old free map was tossed away the information saying not to try to access the bad sect- ors is lossed. Poor AmigaDos recoils in horror upon trying to validate your once full Delux Paint disk. Result: Dpaint become Dpain. If your version of Delux Paint ever gives out, don't hesitate to send it back for replacement by EA. They'll be glad to replace any disk damaged by this error. ------------------------------------------------------------- Well, that's all for this month. Be sure to catch the Screen Image Printer included in this issue. The note on message passing was intended to lay the ground work for a discussion next month on how SCRIMPER works (specifically, how to do screen dumps). Be well everybody and remember to become militant with respect to bad media coverage of the Amiga!